1. Field of the Invention
The present invention relates to a trading system and in particular to a trading system which supports dynamic communications between software units called objects in a distributed object oriented environment based on the CORBA method.
The CORBA (Common Object Request Broker Architecture) method is a standard architecture of the distributed object oriented environment which is provided by OMG (Object Management Group) for realizing the distributed object oriented environment. Equipments of the distributed object oriented environment are to be presented by each vendor according to this standard.
In the distributed object oriented environment in conformity to the CORBA method, processing requests can be transferred between objects and the processings can be realized by the cooperation of the objects without worrying about the differences of architectures and operating systems of computers or of programming languages.
Requests/responses between clients and servers in the CORBA method are mediated by an object request broker (ORB). In the CORBA method, functions such as naming service or trader service which are generally required in a distributed object environment are defined besides the broker. Efficiency in construction of the distributed system can be further improved by using such services as common facilities.
In the CORBA method, a concept corresponding to an object in the object oriented method is called an interface and a concept corresponding to a method is called an operation, so that a client is required to obtain an interface reference (a reference type for object in C++) in order to call a server.
When an operation in an interface reference is called, a corresponding method in a remote server is called automatically. Namely, for the processing of the CORBA method, the interface reference of a desirable server to be called should be obtained in the first place. In the CORBA method, for clients to obtain interface references, several common facilities are supposed as mentioned above. The naming service is a service in which the server name and the server entity correspond to each other, e.g. a service corresponding to searching a telephone number of a person to be called in white pages. On the other hand, the trader service corresponds to a service for searching a telephone number of a person to be called in yellow pages, which is expected as a trading system where the server name and the server entity need not correspond to each other.
2. Description of the Related Art
Such a trading system corresponds to a broker ORB shown in FIGS. 31A and 31B, comprises a plurality of clients 4 and 5 and a trader 1 as shown in FIG. 31B, and performs (1) service type registration processing and (2) service import/export processing as described below:
a) A client 3, which may be any client, requesting the registration of a service type gives a service type name and its super type name, a property definition which defines a property name, type, and mode, and an interface name to the trader 1, thereby requesting the registration of a new service type.
a) The server client 4 which is called an exporter gives the service type name, a property value, and its own interface reference to the trader 1, thereby requesting the registration of the service. In response, the trader 1 maintains the correspondence between the service type and the interface reference of the server.
b) The client 5 which is called an importer gives a necessary service type name, a constraint, and the like to the trader 1, thereby requesting the offer of service information. The trader 1 selects services which conform to the service type, conditions of the constraint, and the like.
c) The trader 1 returns the information of a service group selected in the procedure b) to the client 5.
d) The client 5 uses the interface reference received from the trader 1 to call an object of the server 4.
Processings between the trader 1 and its clients (hereinafter collectively referred to with a symbol xe2x80x9c7xe2x80x9d) will now be described referring to FIG. 32.
For each type of the above-mentioned service type registration processing (1) and service import/export processing (2), and the like, the trader 1 comprises an interface 11 and a processing portion 12. The service type information saved by the trader 1 is saved in a service type repository 13 in the trader 1, and the service information is saved in a service offer repository 14 in the trader 1.
Receiving a processing request from the client 7 at the corresponding portion within the interface 11, the trader 1 transfers the processing to the corresponding portion of the processing portion 12. Each processing portion 12 takes out suitable information from the service type repository 13, the service offer repository 14, or an interface repository 6 which is located outside of the trader 1 to perform the processing. The processing result is returned to the client 7 of the trader 1 through the interface 11.
Next, details of internal processing of such a trading system will be described below:
When newly registering a service type, the service type registration requesting client 3 calls a service type registration interface 131 of the trader 1.
Extracts from a CORBA.IDL definition for the service type registration are given as follows:
IncarnationNumber add_type (
in CosTrading::ServiceTypeName name,
in Identifier if_name,
in PropStructSeq props,
in ServiceTypeNameSeq super_types
):
Having received a registration request from the service type registration interface 131, a service type registration processing portion 132 takes out super type information corresponding to a super type name in the registration request from a service type repository 13. The processing portion 132 also takes out interface definition information of the service in the registration request from the interface repository 6 which is located outside of the trader 1.
The trader 1 examines the correspondence between a super type-sub type relationship in the service type repository 13 and a successional relationship of the interface definition in the interface repository 6, confirms the validity in case both relationship correspond mutually, and saves a new service type in the service type repository 13.
When the processing ends normally, the service type registration interface 131 allots an incarnation number to the registration processing and returns the processing to the service type registration requesting client 3.
(2.1) Service Export Processing (see FIG. 33B)
In the export processing of a service, the exporter 4 calls an export interface 141 of the trader 1. Extracts from a CORBA.IDL definition for this are given as follows:
OfferId export (
in Object reference,
in ServiceTypeName type,
in PropertySeq properties
);
Having received an export processing request from the export interface 141, an export processing portion 142 takes out service type information designated in the request from the service type repository 13. If a property type in a parameter coincides with the property type in a service type definition and if a property value of an mandatory mode is given in the export processing request, the request is valid, so that the trader 1 stores the service in a service offer repository 14.
When the processing ends normally, the export interface 141 returns an offer ID to the exporter 4.
(2.2) Service Import Processing (see FIG. 33C)
In the import processing of a service, the importer 5 calls an import interface 151 of the trader 1. Extracts from a CORBA.IDL definition for this are given as follows:
void query (
in ServiceTypeName type,
in Constraint constr,
in Preference pref,
in PolicySeq policies,
in SpecifiedProps desired_props,
in unsigned long how_many,
out OfferSeq offers,
out OfferIterator offer_itr,
out PolicyNameSeq limits_applied
);
Having received an import processing request form the import interface 151, an import processing portion 152 takes out service type information designated in the request from the service type repository 13, and performs the processing according to the following procedures (see FIG. 34).
1) Extract the service type name designated in the import processing request and service information of the sub type from the service offer repository 14.
2) Calculate a constraint expression in the import processing request based on the property value of each service and select the services for which the expression value becomes true as an import processing object.
3) Sort the services to be import-processed based on a preference in the import processing request.
4) Return a number of services to the importer as designated by a policy parameter in the import processing request.
By applying this trading system to the distributed object oriented environment, the flexibility between the clients and the server is increased and the efficiency in system designing, mounting, and operation is improved. However, there still remain problems as under-mentioned:
[1] Collision of Service Type Names
A service type name in a trader must be unique. Therefore, when a registration processing of a service type in the trader is tried, there are cases where the names collide. For example, a communication service xe2x80x9cAsynchronous Transfer Modexe2x80x9d and a financial service xe2x80x9cAutomatic Teller Machinexe2x80x9d cannot be registered the same name xe2x80x9cATMxe2x80x9d, so that they must have different names.
Also, in the export processing of a service offer, the trader does not know in what intention the exporter classified its own service into the service type, that is, whether the xe2x80x9cATMxe2x80x9d means the xe2x80x9cAsynchronous Transfer Modexe2x80x9d or the xe2x80x9cAutomatic Teller Machinexe2x80x9d. In the import processing, the trader cannot know the meaning of the service type name designated by the importer.
On the other hand, there is a link or the like as means for the cooperative operation of a plurality of traders. In the presence of a link, the import processing request is transferred accordingly, but contradictions are caused unless the meanings of the service types and the services are in conformity among the traders.
For example, if the service type xe2x80x9cATMxe2x80x9d is used as meaning the xe2x80x9cAsynchronous Transfer Modexe2x80x9d in a trader while as meaning the xe2x80x9cAutomatic Teller Machinexe2x80x9d in another trader, the mixed services of different meanings are to be offered to the importer.
[2] Client Authentication by Trader
A trader receives export processing requests from various exporters to construct a service offer repository. Also, it receives service type registration requests from various clients to construct a service type repository.
A trader is an object forming a basis of the distributed environment so that the information in a trader must not be rewritten illegally or carelessly. Therefore, it is necessary to incorporate such an authentication means that a certain service type can only be registered from a certain object into an interface between a trader and its client which is closely linked with the functions of the trader.
[3] Import Processing Authority
For security reasons and the like, there are cases where an exporter desires to make the service available only from limited clients (importers). In such cases, the trader can even offer the whereabouts of the service to the importer as usual and perform some kind of authentication processing between the server and the client. However, in order not to inform the importer of the existence of the server carelessly, it is preferable to be able to designate for the trader the range where the service can be opened to public at the time of the export processing.
However, in the existing trading system, it is not possible to designate a range where the service can be opened to public at the time of the export processing nor to indicate the authority indicating the service which enables the import processing by the importer.
It is accordingly an object of the present invention to provide a trading system which avoids the collision of service type names or enables a client authentication by a trader or authority assignment for import processing.
[1] Collision of Service Type Names
This problem is caused by the fact that there is no means for indicating the contents of service type/service offer in more detail than the service type name and the property in the form recognizable by the trader. The trader only determines the coincidence/non-coincidence (agreement/disagreement) at the time of export processing/import processing with regard to the service type name as a mere character string and does not judge the meaning of the service type name. In order to deal with this problem, it is necessary to describe the meaning of the service type in a machine-recognizable and extensible form.
[2] Client Authentication by Trader
This problem is caused by the fact that there is no procedures for indicating information related to such a client of the trader as an import processing requestor or a service type registration processing requester. This problem can be dealt with by installing a mechanism for the client of the trader to affix signature information to the processing request in order to indicate that the request has been issued by a proper client and a mechanism for the trader to decrypt the signature information and to compare the information with the authority information.
[3] Import Processing Authority
This problem is also caused by the fact that there is no procedures for indicating the information related to such a client of the trader as the import processing requestor or the service type registration processing requester. This problem can be dealt with by installing a mechanism for indicating the identity of the importer to the trader. In order to perform an efficient authentication, an authentication procedure by a challenge-response procedure is required.
Means for realizing the above-mentioned viewpoints will be described hereafter, respectively.
[1] Context-based Trading Processing
An arrangement of the present invention according to claim 1 is shown in FIG. 1A. The client 7 of the trader 1, which may be a service type context registration requesting client, a service type registration requesting client, an exporter, an importer, or the like, individually describes, at a metadata generating portion 75, a character string type parameter of an operation made at a request processing portion 71 with metadata including a service type and a service type context which is a supplementary or generic information of the service type and transfers the same to the trader 1 through an interface 72.
In the trader 1 which receives the processing request from the client 7, the interface 11, as stated in claim 8, can be the one common to the prior art trader. However, a metadata interpreting portion 15 which interprets the received processing request as a metadata, or data describing data, and extracts the character string type parameter of the operation, and a metadata generating portion 16 which transforms the processing result at a processing portion 12 into metadata are provided between the interface 11 and the processing portion 12
Also, as a database to which the processing portion 12 refers, there are the service type repository 13, within the trader 1, which saves the service type information including the service type context and the service offer repository 14 which saves the information of the export-processed service existing as stated in claims 10 and 11. Moreover, there is an interface repository 6 existing outside of the trader 1, as stated in claim 12, which is a database for saving a service interface definition required for examining the conformity of the service type.
On the side of the client of the trader 1, a metadata interpreting portion 76 which interprets the response received from the trader 1 as a metadata is provided between the request processing portion 71 which requests the processing to the trader 1 and the trader interface 72 which interfaces with the trader besides the above-mentioned metadata generating portion 75.
An arrangement of the present invention according to claim 2 is shown in FIG. 1B. The difference from FIG. 1A is that the interfaces of the trader 1 are made a common interface 17.
Namely, in the client 7, contents of the request processing are transformed all together into a metadata description at the metadata generating portion 75 and transferred to the trader 1 through the interface 72. In the trader 1, the processing request is received at the common interface 17 and the whole processing request is interpreted as a metadata at the metadata interpreting portion 15.
After the interpretation, the processing is dispatched to each part of the processing portion 12 according to the contents, or the parameters, of the processing request which are contained in the metadata description. The processing result is returned to the client 7 after being transformed into a metadata form at the metadata generating portion 16.
In FIG. 1B, as an arrangement corresponding to claims 3-7, an authentication processing portion 18 is provided, as shown by dotted lines, which is called as required from each part of the processing portion 12 to perform an authentication processing.
Effects of the present invention having such compositions will now be described.
In each claim, the service type context is defined as supplementary information, or generic information, of the service type in order to avoid the collision of service type names and the confusion of concepts indicated by the service types. A name space of the service type name is divided according to the service type context. If the service type contexts are different, the service type names do not collide. A schematic example of the information within the service type repository 13 in which the service type name space is structured by the service type context is shown in FIG. 2A, which will be described as follows:
(1) Service Type Structure (see FIG. 2A)
The name space of the service type (abbreviated as SvcType shown) name composed of the service type name is divided according to the service type contexts into contexts such as X, Z, and X.Y.
An inclusive relationship can be set between service type contexts. In this example, the context X includes the context X.Y.
A default context 130 which includes the whole set of service types is defined. The default context 130 includes all of the service type contexts directly or indirectly. In this example, the default context 130 directly includes SvcTypes A, D, and E.
As long as the service type contexts are different, a plurality of service types having the same name can exist. In this example, the SvcType A exists in the default context 130, the service type contexts X.Y and Z.
How to handle the service type contexts in the trader will now be described.
A trading processing flow based on the service type context is shown in FIG. 4. Namely, the client 7 which requests the processing to the trader 1 adds the service type context name which is the supplementary information of the service type name as a service type name parameter within the processing request and transforms the same into the metadata description at the metadata generating portion 75. The metadata-described parameter is transferred to the trader 1 with other parameters through the interface 72.
Having received the processing request at the interface portion 11 (step S1), the trader 1 interprets the metadata-described parameters at the metadata interpreting portion 15 (step S2), and transfers the request to each part of the processing portion 12. After the processing is finished in each part of the processing portion 12 (step S3), the processing result is transformed into the metadata description at the metadata generating portion 16, and transferred to the origin of the processing request through the interface 11 (step S4).
Having received the processing result, the client 7 interprets the metadata-described parameters in the response at the metadata interpreting portion 76 and performs the processing according to the response result at the request processing portion 71.
The processings within the trader 1 based on the concept of the context will now be described.
(2) Service Type Context Registration Processing (see FIG. 2B)
In an initial state of the service type information within the service type repository 13 (see FIG. 2A), if the trader 1 receives a request with the default context 130 designated as a superior service type context to newly register a service type context W, the trader 1 generates the new service type context W, shown by a thick line, within the default context 130.
(3) Service Type Registration Processing (see FIG. 2C)
The case where the service type context X.Y is designated with FIG. 2B being made the initial state and a new service type E is registered under a super type A is considered.
The trader 1 retrieves the service type context X.Y and generates the new service type E as a sub type of the service type A if the existence of the service type A within the context X.Y is confirmed.
Although the service type A exists in the default context 130 and the context Z besides the context X.Y, the service type which assumes the super type can be uniquely determined since the concept of the context functions.
(4) Export Processing (see FIG. 2D)
The case where the service type context Z is designated with FIG. 2C being made the initial state and a new service is export-processed to a service type D is considered.
The trader 1 retrieves the service type context Z and registers a new service NSVC in the service type D if the existence of service type D within the context Z is confirmed. Although the service type D exists in the default context 130 besides the service type context Z, the service type of the new service can be uniquely determined since the concept of the context functions.
(5) Import Processing (see FIGS. 3A-D)
The case where the trader 1 receives an import processing request in the state of FIG. 2D is considered. According to the service type name in the import processing request and the service type context designation, the service type of the service which is the import processing object will be determined as follows:
In case the service type A is import-processed without a context designation, the service type A and its sub types, i.e. the service type D and the service type E, existing within the default context 130; the service type A and its sub type, i.e. the service type E, existing within the service type context X.Y included in the default context 130; and the service type A within the service type context Z correspond therewith (see FIG. 3A).
In case the service type A is import-processed by designating the service type context X, the service type A in the context X.Y within the service type context X and the service type E which is the sub type of the service type A correspond therewith (see FIG. 3B).
In case the service type E is import-processed by designating the service type context Z, there is no corresponding service type since the service type E does not exist within the service type context Z (see FIG. 3C).
In case the service type E is import processed by designating the default context, there is no context designation, so that the service type E in the default context 130, the service type E in the context X, and the service type E in the context X.Y correspond therewith (see FIG. 3D).
[2] Authentication of Trader""s Client
In the present invention according to claims 3-7, 11, and 13, an authentication of the trader""s client is performed. The client 7 of the trader 1 can set authority information in the service type context, the service type, and the service within the repository 13 possessed by the trader, and the client 7 must present in the processing request a signature coinciding with the authority.
(1) Authentication Processing Arrangement (see FIG. 5)
The authentication is performed at the times of the service type context registration, the service type registration, the service export, and the import processing.
The client 7 of the trader 1 transforms the authentication information indicating that it has the authority to make the processing request and the authority information to be set in the information generated as a result of the processing, such as the service type context, the service type, and the service, together with other parameters of the processing request, into a metadata form at the metadata generating portion 75, which is transferred to the trader 1 through the interface 72.
Having received the processing request from the client 7 through the common interface 17, the trader 1 interprets and extracts the above-mentioned authority information and authentication information at the metadata interpreting portion 15, and then determines at the authentication processing portion 18 with this authentication information whether or not the client 7 has the authority for the request.
If the authority is recognized, the trader 1 performs the ordinary processing at each part of the processing portion 12 and sets the authority information in the generated information, such as the service type context, the service type, and the service. The processing result is transformed into the metadata description at the metadata generating portion 16 and returned to the client 7 through the interface 17.
(2) Client Authentication Procedure (see FIG. 6)
The client 7 of the trader 1 can set the authority information in the service type context, the service type, and the service to be registered in trader 1. The authority information is described in metadata with other parameters and transferred to the trader (step S1). Setting the authority information enables restrictions such as not accepting the processing if an appropriate signature is not affixed in the following request from the client.
Having received the request from the client, the trader extracts the authority information at the metadata interpreting portion (step S1), and stores the same in the service type repository or the service offer repository as follows:
1) An authority information for restricting the client 7 capable of registering a subordinate service type context included in a new service type context is stored in the service type repository 13 with the context information (claims 3, 11).
2) An authority information for restricting the client 7 capable of performing the registration processing of a sub type under a new service type is stored in the service type repository 13 with the service type information (claims 4, 11).
3) An authority information restricting the client 7 capable of performing the registration processing of a new service type under a new service type context is stored in the service type repository 13 with the service type context information (claims 5, 11).
4) An authority information for restricting the client 7 capable of performing the export processing of a service as a service type is stored in the service type repository 13 with the service type information (claims 6, 11).
5) An authority information for restricting the client or importer acapable of performing the import processing of a service to be registered is stored in the service offer repository 14 with the service information (claims 7, 11, 13).
Namely, in the present invention according to claim 7, the authentication processing of the importer is performed based on the authority enabling the import processing of the service designated by the exporter (step S5). The exporter can set the authority information to the service to which the exporter itself has performed the export processing, while the importer must present in the import processing request the signature coinciding with this authority.
After having decided whether or not it is a valid processing request at each part of the processing portion 12 (steps S6, S3), the authority information for restricting the importer of the service is stored in the service offer repository 14 of the trader 1 as a result of the authentication (step S7).
(3) Importer Authentication Procedure
The authentication of the importer is performed according to a challenge-response procedure between the trader and the importer. The processing flow between the trader and the importer at the time of authentication is shown in FIGS. 7A and 7B, which will be described herebelow referring to FIG. 8.
1) Having received the import processing request, the import processing portion 12 in the trader 1 requests the authentication processing portion 18 to generate the challenge information for authenticating the importer or the client 5 (step S8). The generated challenge information is transformed into the metadata description at the metadata generating portion 16 and transferred to the importer 5 for inquiry (step S9).
2) The importer 5 hashes or simply encrypts the received challenge information after encrypting the same with its own private key and responds to the trader 1 with the metadata-described information of the encryption method and the hash method.
3) Having received the response from the importer 5, the trader 15 compares the encrypted and hashed information with the challenge information at the authentication processing portion to perform the authentication (step S10), and returns the import processing result in the same way as the ordinary import processing if the response is found appropriate (step S11).
Thus, the trading system according to the present invention introduces a metadata description for the request parameter and the response parameter transferred between the trader and its client, thereby enabling the service type context of the service type, the authentication information, the authority information of the client, and the like to be described in a strict and extensible form.